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1.0 INTRODUCTION 

The intended audience is anyone who wants to check whether their STRS application or STRS 
infrastructure meets the STRS Architecture Standard. This includes platform providers, application 
developers, application integrators, and NASA. As of May, 2011, only NASA Glenn Research Center 
personnel have performed the STRS Compliance Testing. 

1.1 Identification 

The document describes the procedures for testing a software defined radio (SDR) implementation for 
STRS compliance. STRS compliance is concerned with how well the delivered artifacts conform to the 
STRS Architecture Standard. Broadly, STRS compliance may be categorized as either STRS application 
compliance or STRS infrastructure (OE) compliance. Within those categories, STRS compliance may be 
categorized as static or dynamic. Static STRS compliance is whether the code, configuration files, and 
documentation conform to the STRS Architecture Standard. Dynamic STRS compliance is whether the 
components execute properly together to become a functioning STRS radio. This document is mostly 
concerned with static STRS compliance by inspecting code, configuration files, and documents. 


STRS OE compliance is depicted in Figure 1 : 


Implements STRS InfrastructureAPI 
Uses STRS Application API 
Uses HALAPI 

rSupports WF 
►Supports Device 
►Supports File 
‘■Supports Queue 

^Supports health/fault management 
^Parses configuration files 
*BIT 
WDT 

Document ►HAL, HID, etc. 

Figure 1 - Operating Environment Compliance 

For the STRS OE, compliance includes: 

a. Implements required STRS infrastructure-provided APIs using standard “C” language interface 

b. Provides necessary header files for application developers 

c. Provides necessary run-time infrastructure to support STRS infrastmcture-provided and STRS application- 
provided APIs 

d. Provides POSIX 1003.13 PSE51 conformant OS or a POSIX abstraction layer. Very small platforms can 
provide the minimum subset of PSE5 1 required to support mission waveforms (with a waiver) 

e. Verify configuration files, describing the platform resources, in XML, using the corresponding schema 

f. Test vendor supplied XML transformation tools with sample file 

g. Confirm documentation 

i. Configuration files 

ii. Flight computer 

iii. Hardware Abstraction Layer (HAL) API 


STRS 



Dynamic 

(debug) 
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iv. Hardware Interface Description (HID) 

v. Firmware interface to platform-specific wrapper 

vi. User’s Guide 

vii. Reference Manual 

viii. Test plan 
h. Coding standards 

For the STRS OE, compliance does not include: 

a. Memory footprint 

b. OE performance (Operations/second, interrupt response, etc.) 

c. Size, weight, and power (SWaP) 

d. Shake and bake, radiation tolerance 

e. NASA flight software/hardware requirements 


STRS application compliance is depicted in Figure 2 

/Static- 

STRS ►WF " 


Dynamic 

(debug) 




Implements STRS Application API 
Uses POSIXAEP 
Uses STRS Infrastructure API 
Uses configuration files 


WF executes (not performance) 
WF signal interoperates 
(not STRS responsibility) 


Document 


Figure 2 - Application Compliance 

For an STRS application, compliance includes: 

a. Implements required STRS application-provided API per STRS Architecture Standard 

b. Verify that the only external interfaces called by the STRS application are the STRS infrastructure-provided 
APIs and allowed POSIX PSE51 APIs 

c. Verify that STRS application does not call restricted functions documented in section 8.5.1 of the STRS 
Architecture Standard 

d. Verify dynamic behavior of STRS application 

i. Application responds properly to STRS application-provided API 

ii. Application exhibits proper state transition behavior 

e. Verify that the STRS application uses the STRS predefined data 

i. typedefs 

ii. constants 

iii. structs 

f. Verify configuration files, describing the STRS application, in XML, using the corresponding schema 

g. Test vendor supplied XML transformation tools 

h. Verify FPGA wrapper provided (if platform has FPGA) 


Verify 

documentation 

i. 

Design 

ii. 

Models 

iii. 

Test plan 

iv. 

User’s Guide 

V. 

FPGA Wrapper 


j. Model -based design 
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k. Coding standards 

For an STRS application, compliance does not include: 

a. Memory footprint 

b. Over the air behavior of waveform 

c. Interoperability 

i. Performance (BPS, BER, etc) 

ii. Functional Requirements to meet missions objectives; other than being compliant with STRS 
architecture 

d. NASA flight software requirements 

l. 2 System Overview 

Compliance testing determines to what degree the tested STRS application or STRS infrastructure in a 
software defined radio (SDR) implementation meets the STRS Architecture Standard. The purpose of 
having a standard architecture is to allow different companies to work together or separately, at the same 
or different times, to create a software defined radio. STRS requirements may be verified by inspecting 
documents, code, configuration files, and other artifacts, as well as observation. A component is 
compliant when a subset of the features in the specification is implemented in accordance with the 
architecture specification. A component is conformant when all the features in the architecture 
specification are implemented in accordance with the specification. 

There are four methods used to test for STRS compliance described in this document: automated 
inspection, manual inspection, observation, and execution of an STRS application that tests the standard 
STRS capabilities. Although most of the automated tests may be performed manually, validation of the 
STRS OE, an STRS application, or STRS configuration file is facilitated by automated tools. 

• Automated inspection uses a variety of tools to look for the required artifacts and lists those that are 
problematic. 

• Manual inspection is used to augment the automated inspection methods especially when the other 
methods cannot be done. 

• Observation is performed by the project verification and validation team. 

• The insertion of an STRS application created by GRC (WFCCN) into the radio and execution of 
that waveform application to test the capabilities of the radio can be used to exercise all the required 
STRS application-provided methods beginning with “APP_” and STRS infrastructure-provided 
methods beginning with “STRS ”. 

1.3 Document Overview 

The document contains an Introduction, Applicable Documents, Test Configurations, and Test Descriptions. 
There is a table of all the requirements being tested, general test instructions, and test instructions associated 
with 4 groups of semi-automated tests and 2 groups of manual tests. The groups are separated by 
Infrastructure (OE) depicted in Figure 1 and Application (WF) depicted in Figure 2, as well as the available 
automated procedures. 

In the event of a conflict between the requirements in this document and the requirements in the STRS 
Architecture Standard, the requirements in the STRS Architecture Standard shall take precedence over this 
document. 

The artifacts to be tested and the results of testing are often proprietary to NASA and the supplier of the 
artifacts. The results of testing are used to inform the supplier of any deficiencies as well as providing lessons 
learned to NASA. 
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2.0 APPLICABLE DOCUMENTS 

2.1 Reference Documents 

Table 1 lists the number and title of all documents referenced in this specification. 

Table 1 - Table of Documents 


Document number 

Document title 

* 

Altova XPLSpy® Professional Edition Online Manual 
http://manual. altova.com/XMLSpv/sDVDrofessional/ 

GLPR 7150.1 

Glenn Research Center (GRC) Software Engineering Requirements 

NPR 7150.2A 

NASA Software Engineering Requirements 

GRC-TPLT-STPr 

Software Test Description Template 

NASA/TM-20 10-2 16809 

Space Telecommunications Radio System (STRS) 

Architecture Standard, STRS AR 0002, Revision 1.02.1. See 
http://ntrs. nasa.gov/archive/nasa/casi.ntrs.nasa. gov/201 10002806 20 
11001718.Ddf 

NASA/TM-2008-2 15445 

Space Telecommunications Radio System (STRS) 

Definitions and Acronyms. See 

http://ntrs. nasa.gov/archive/nasa/casi.ntrs.nasa. gov/20090005977 20 
090049 14.pdf 

STRS-OE-00002 

Space Telecommunications Radio System (STRS) 
Reference Implementation User’s Guide 

* 

Tornado development environment documentation in TVL 

* 

VxWorks operating system documentation in TVL 

DOC-12067-ZD-00 

VxWorks Programmers Guide 5.3.1 at 

http ://www-cdfonline. fnal. gov/ daa/commercial/vxworks guide .pdf 


3.0 TEST CONFIGURATIONS 

3.1 Hardware Configuration 

The SDR-3000 development PC in the Technology Verification Lab (TVL) was used for these tests because 
all the software (scripts, compiler, Subversion CM tool, GRC’s STRS reference implementation, Cygwin, etc.) 
ran on it and the software to be tested was kept in Subversion CM tool accessible to the SDR-3000. The SDR- 
3000 uses an Ethernet connection to store and obtain artifacts to/from the Subversion CM server. The SDR- 
3000 and its development PC is shown in Figure 3. Other hardware platforms may work as well if the 
appropriate software is loaded. 
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Figure 3 - SDR-3000 and Development Platform 


Table 2 is used to record information about the hardware used for testing purposes. 

Table 2 - Hardware Used 


Name 

Part 

Model 

Serial 

Number 

Manufacturer 

Revision 

Level 

Calibration 

Date 

SDR-3000 




Spectrum 

Signal 

Processing 

VxWorks 

5.5.1 

NA 

SDR-3000 

Development 

PC 

800-00257 


SS4903- 

00132 

Spectrum 

Signal 

Processing 

Win2000 

SP4 

NA 


3.2 Software Configuration 

This paragraph describes the procedures necessary to prepare the item(s) under test and any related 
software, including data, for the test. Reference may be made to published software manuals for these 
procedures. The following information is to be provided, as applicable: 

a) The specific software to be used in the test including version number and name 

1 . STRS Application Automated Testing 

a. Windows batch file: STRS/Compliance/ComplianceTool.bat 

b. Bourne shell script: STRS/Compliance/ComplianceTool.sh 

c. STRS application files in Subversion to be tested 

2. STRS Infrastructure Automated Testing 

a. Windows batch file: STRS/Compliance/ComplianceToolOE.bat 

b. Bourne shell script: STRS/Compliance/ComplianceToolOE.sh 

c. STRS infrastructure files in Subversion to be tested 
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3. STRS Infrastructure Testing Using WFCCN 

a. STRS application source file CommandAndComplianceApplication.cpp 

b. STRS application header file CommandAndComplianceApplication.h 

c. VxWorks cross-compiler ccppc or equivalent 

d. STRS infrastructure files in Subversion to be tested 

4. STRS Configuration File Testing 

a. XMLSpy or equivalent 

b. STRS configuration files in Subversion to be tested 

b) The storage medium of the item(s) under test (e.g., magnetic tape or diskette) 

Hard disk 

c) The storage medium of any related software (e.g., simulators, test drivers, or databases) 
Hard disk 


Table 3 is used to record information about the software used on the SDR-3000. 

Table 3 - Software Used 


Name of software 

Version number 

ComplianceTool.bat ( Windows batch file) 

SVN 1067 (12/4/2009) 

ComplianceTool.sh (Bourne shell script) 

SVN 1118(1/27/2010) 

ComplianceToolOE.bat (Windows batch file) 

SVN 1069 (12/4/2009) 

ComplianceToolOE.sh (Bourne shell script) 

SVN 1624 (7/13/2010) 

CommandAndComplianceApplication.cpp (WFCCN) 

SVN 1099(1/12/2010) 

CommandAndComplianceApplication.h (WFCCN) 

SVN 1070 (12/4/2009) 

ccppc 

gcc-2.96 

Cygwin - GNU bash 

2.05b.0(l) 

Tortoise SVN 

1.6.18415 

XMLSpy 

Altova XMLSpy Professional 2011 (COTS) 


3.3 Other Pretest Preparations 

Find and copy the STRS application (WF) and/or infrastructure (OE) items being tested to the computer 
on which the tests will be executed. For example, at GRC, enter the items to be tested into Subversion 
using the SDR-3000 or other PC in the TVL and extract from Subversion to the SDR-3000. 

4.0 TEST DESCRIPTIONS 

There are multiple test procedures used to test for STRS compliance. The requirements are all shown in 
Table 19 even though only certain tests have been automated and only certain tests can have detailed 
descriptions of how to perform an inspection. 
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4.1 Requirements Being Tested 

The full range of tests is listed in Table 19. To aid the tester, there are four types of semi-automated tests. Two 
types of manual source code tests are also described. 

1. For STRS Application Automated Testing, the requirements in Table 19 have the entry for OE/App as App 
and the entry for Tested as Script. 

2. For STRS Infrastructure Automated Testing, the requirements in Table 19 have the entry for OE/App as 
OE and the entry for Tested as Script. 

3. For STRS Infrastructure Testing Using WFCCN, the requirements in Table 19 have the entry for OE/App 
as OE and the entry for Tested as WFCCN. 

4. For STRS Configuration File Testing, the requirements in Table 19 have the entry for OE/App as App and 
the entry for Tested as XMLSpy. 

5. For STRS Manual Application Testing, the requirements in Table 19 have the entry for OE/App as App 
and the entry for Tested as Inspect. 

6. For STRS Manual Infrastructure Testing, the requirements in Table 19 have the entry for OE/App as OE 
and the entry for Tested as Inspect. 

4.2 Test Instructions 

There are no general instructions for executing the test procedures. If there are any questions or problems that are 
not resolved by this document or the referenced documents , email: STRSfelists. nasa.gov. 

4.3 STRS Compliance Testing 

STRS compliance testing is performed on software defined radio artifacts. Even when there is an 
automated procedure, it is necessary to check any warnings or errors manually to be sure that the error or 
warning does not indicate a false positive. The general procedure is shown in Figure 4. 
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Start script 



Mark error or 
warning against 
requirement 


C “ ) 


Figure 4 - General Automated Procedure with Manual Double-Check 

4.3.1 Prerequisite Conditions, Assumptions, and Constraints 

The prerequisite conditions and assumptions are minimal: 

a) For testing of code and configurations files, the PC containing those artifacts must be available and 
turned on. For GRC’s testing, the STRS-3000 development PC must be available and turned on. 

b) The test shell scripts are limited to testing method signatures, prototypes, constants, and typedefs that 
appear entirely on a single line. Lines of code with errors or warnings are then tested with a manual 
procedure, directly against the requirement. 

c) Use a browser on the reviewer’s PC to access documents in eRoom or CMTS. 

d) The artifacts to be tested and results of testing are to be considered proprietary to NASA and the 
company submitting the artifacts. 

e) It is assumed that everything works as described. For unusual situations, refer to the documentation in 
Table 1 - Table of Documents. 

f) Waivers or exceptions are the project responsibility, not STRS; however, they must be documented 
and submitted to the STRS repository. 

4.3.2 Test Procedure for STRS Application Automated Testing 

A UNIX Bourne shell script named ComplianceTool.sh was written to test for the various STRS application- 
provided method signatures beginning with “APP” and STRS infrastructure -provided method signatures beginning 
with '‘STRS ” as well as to search for deprecated methods, disallowed POSIX methods, and non-portable 
QuicComm methods. The script also tests for “non-standard APP methods”, “extra APP methods”, and “extra STRS 
methods”. 


NASA/TM— 20 11-217266 


13 







Space Telecommunications Radio System (STRS) Compliance Testing 

Date: May 31,2011 

Document No.: STRS-ATP-00001 

Page 14 of 46 


The compliance tool looks for the required artifacts in the source code and lists those that are problematic. The 
number of required STRS application-provided methods beginning with “APP” may vary depending on the 
application. If the STRS application is a source of data supplied to the infrastructure, the standard requires the 
STRS application to have an APP Read method. If the STRS application is a sink that receives data from the 
infrastructure, the standard requires the STRS application to have an APP Write method. The STRS Architecture 
Standard defines 43 distinct STRS infrastructure -provided methods beginning with “STRS_”. The maximum 
number of required STRS application-provided methods beginning with “APP” that an STRS application can have 
is 11 and the minimum number is 9. The STRS application-provided methods beginning with “APP_” are described 
in the STRS Architecture Standard. 

The following terminology is used in the statistics. “Full signature” means a method declaration or definition as 
described in the STRS Architecture Standard including the return type, name, and definition of the arguments. 
“Non-standard APP methods” represent those STRS application-provided methods beginning with “APP” that do 
not contain a full signature as described in the STRS Architecture Standard. “Extra APP methods” represent those 
methods that begin with “APP ” but are not defined in the STRS Architecture Standard. Although APPSetBT is 
included in the reference implementation, APP SetBT is not standard and is included as an extra method. “Distinct 
STRS methods out of 43” report how many of the Standard’s 43 methods occur. “Extra STRS methods” represent 
those methods that begin with “STRS ” but are not defined in the STRS Architecture Standard. 

The compliance tool was written for the Bourne shell (sh) and may be executed by any superset of sh such as the 
Bourne-again shell (bash), which is available with Cygwin on the SDR-3000 (or OE1). Cygwin is a Linux-like 
environment for Windows. For more information on Cygwin, see http://www.cygwin.com/ . There is also a MS 
Windows batch file that may be used to execute ComplianceToolOE.sh by either double clicking on 
ComplianceTool.bat or entering the file location in a DOS command window. ComplianceTool.bat is in the same 
directory as ComplianceTool.sh. 

The step-by-step procedure for performing these tests is shown in Table 4. A test operator should fill in the blank 
columns and additional information following the table to show compliance. 


Table 4 - STRS Application Test Automated Procedure 


Step 

Require- 
ment ID 

Test Operator Action 

Expected Result 

Actual 

Result 

Pass 

or 

Fail 

1 


Find/obtain the compliance testing script(s) and 
put into a common directory. The files are: 
ComplianceTool.sh . ComplianceTool.bat , and 
removeComments.awk .which may be obtained 
in the TVL from the Subversion configuration 
management tool at directory: 
ComplianceToolScript/ 
or the files may be found in the CoNNeCT 
eRoom at: 

CoNNeCT > Principal Investigator > STRS > 
Compliance > 

Record the directory where the compliance 
testing scripts are stored. 




2 


Find the STRS application source files to be 
tested. Record the directory where the files are 
stored. 




3 


Change directory to that containing the 
compliance tools. 




4 


Start test by typing 
sh ComplianceTool.sh 

in a UNIX (Cygwin, bash) command window or 
double-clicking: ComplianceTool. The script 
will display progress as it executes. 

Compliance tool prompts 
for source directory or file. 
The prompt string is “Enter 
directory or source file to 
test for STRS compliance 
(or Q, C, or?):”. 
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5 


Enter source directory or file to test. The file or 
directory may be absolute or relative to the 
directory containing the ComplianceTool 
scripts. Summary of numbers of files and 
methods found and errors is displayed. Enter an 
upper or lower case Q to exit the script. Enter 
an upper or lower case C to search for 
directories containing files with extensions h, H, 
c, C, cpp, and CPP; however, directories 
containing /components/, /corba/, /public_tools/, 
and /sea/ are eliminated. The C entry is not 
usually used because it takes a long time and 
still doesn’t necessarily look in the right places. 

Output file web page 
named 

Complianc eyyyymoddhhmn 
.y.y.html is created for each 
execution of the script 
where yyyymoddhhmnss is 
the date and time when the 
script is invoked. For 
example, see Table 13. 



6 


Display output file in a browser. 

For example, see Table 14. 



7 

STRS-10, 

STRS-20, 

STRS-23, 

STRS-26, 

STRS-29, 

STRS-30, 

STRS-31, 

STRS-32, 

STRS-33, 

STRS-34, 

STRS-35, 

STRS-36, 

STRS-37, 

STRS-38, 

STRS-39, 

STRS-91 

Errors are in red and warnings are in blue on the 
web page output. Check errors and warnings 
manually against requirements to eliminate false 
positives. Record errors, potential problems, 
and discrepancies. Note the associated 
requirement, if appropriate. 




8 


To be sure that there are no additional problems, 
a manual code inspection should be performed 
based on the additional data following the 
summary information. The additional output 
displays the file name, line number, and actual 
line where the problem or potential problem 
occurred. These should be examined and the 
errors corrected to attain compliance. 





Verification (Pass/fail): 


Comments: 


Test operator: Date: 

Product assurance: Date: 
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The Test Operator Action should provide enough detail to enable successful repetition of the test. 

1 . To halt or interrupt the test procedure, press Control-C 

2. If the shell script does not execute properly, the test operator may obtain additional data reflecting the 
execution of the shell script by adding the “xv” options to the script invocation; i.e., from 

sh . \ComplianceTool . sh 


to 


sh -xv . \ComplianceTool . sh 

4.3.3 Test Procedure for STRS Infrastructure Automated Testing 

A UNIX Bourne shell script was written to test for the various STRS required files, typedefs, constants, and structs 
required to be provided in the STRS infrastructure. The required typedefs, constants, and structs are described in the 
STRS Architecture Standard. The shell script creates a web page named Compl i anceO Eyyyymoddhhmnss. him I for 
each execution of the script where yyyymoddhhmnss is the date and time when the script is invoked. The shell script 
checks whether the typedefs, constants, and structs are defined in STRS.h or in a #include file referenced by STRS.h 
contained in the same directory. 

The OE compliance tool was written for the Bourne shell (sh) and may be executed by any superset of sh such as the 
Bourne-again shell (bash), which is available with Cygwin on the SDR-3000 in the TVL. Cygwin is a Linux-like 
environment for Windows. For more information on Cygwin, see http://www.cvgwin.com/ . There is also a MS 
Windows batch file that may be used to execute ComplianceToolOE.sh by either double clicking on 
ComplianceToolOE.bat or entering the file location in a DOS command window. 

The step-by-step procedure for performing these tests is shown in Table 5. A test operator should fill in the blank 
columns and additional information following the table to show compliance. 


Table 5 - STRS Infrastructure Test Automated Procedure 


Step 

Require- 
ment ID 

Test Operator Action 

Expected Result 

Actual 

Result 

Pass 

or 

Fail 

1 


Find/obtain the OE compliance testing 
scripts. The files are 
ComplianceToolOE.sh . 
ComplianceToolOE.sh , and 
removeComments.awk , which may be 
obtained in the TVL from the Subversion 
configuration management tool at 
directory: ComplianceToolScript/ 
or the files may be found in the 
CoNNeCT eRoom at: 

CoNNeCT > Principal Investigator > 
STRS > Compliance > 

Record the directory where the OE 
compliance testing scripts are stored. 




2 


Find the STRS infrastructure source files 
to be tested including STRS.h. Record 
the directory where the files are stored. 




3 


Change directory to that containing the 
compliance tools. 




4 


Start test by typing 
sh ComplianceToolOE.sh 
in a UNIX (Cygwin, bash) command 
window or double-clicking: 

Compliance tool prompts for 
source directory or file. The 
prompt string is “Enter directory 
or STRS.h source file to test for 
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ComplianceToolOE. The script will 
display progress as it executes. 

STRS OE source compliance 
(or Q):” 



5 


Enter source directory containing 
STRS.h or path to file STRS.h. The 
directory may be absolute or relative to 
the directory containing the 
ComplianceToolOE scripts. Names of 
files processed are displayed as well as a 
summary of errors. Enter an upper or 
lower case Q to exit the script. Enter an 
upper or lower case C to search for 
directories containing files STRS.h; 
however, directories containing 
/components/, /corba/, /public_tools/, and 
/sea/ are eliminated. The C entry is not 
usually used because it takes a long time 
and doesn’t necessarily look in the right 
places. 

Output file web page named 
ComplianceOEyyyyiwofiW/i/wm^ 
.y. h trill is created for each 
execution of the script where 
yyyymoddhhmnss is the date and 
time when the script is invoked. 
For example, see Table 15. 



6 


Display the output file in a browser. 

For example, see Table 16. 



7 

STRS- 17, 
STRS-89 

Errors are in red on the web page output. 
Check errors and warnings manually 
against requirements to eliminate false 
positives. Record errors, potential 
problems, and discrepancies. Note the 
associated requirement, if appropriate. 




8 


To be sure that there are no additional 
problems, a manual code inspection 
should be performed based on the 
additional data following the summary 
information. The additional output 
displays the file name, line number, and 
actual line where the problem or 
potential problem occurred. Details are 
displayed showing each individual 
missing item. The STRS infrastructure- 
provided method prototypes missing 
from the OE are also displayed. These 
should be examined and the errors 
corrected to attain compliance. 




9 


The files containing the prototypes for 
each STRS infrastructure -provided 
method are displayed so that the proper 
#include statements may be added to 
STRS applications as necessary. See 
section 4.3.4 below. 





Verification (Pass/fail): 


Comments: 


Test operator: Date: 

Product assurance: Date: 
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The Test Operator Action should provide enough detail to enable successful repetition of the test. 

1 . To halt or interrupt the test procedure, press Control-C. 

2. If the shell script does not execute properly, the test operator may obtain additional data reflecting the 
execution of the shell script by adding the “xv” options to the script invocation; i.e., from 

sh . \ComplianceToolOE . sh 


to 


sh -xv . \ComplianceToolOE . sh 

4.3.4 Test Procedure for STRS Infrastructure Testing Using WFCCN 

Because of the complexity allowed in C/C++, a good way to verify that an STRS application and the STRS 
infrastructure work together properly is by compiling, linking, and executing. To that end, GRC has developed an 
STRS application that implements all the required STRS application-provided (APP_) methods and uses all the 
STRS infrastructure' -provided (STRS ) methods. This command and control application, WFCCN, is inserted into 
the radio and executed to test the compliance of the STRS radio infrastructure to the STRS Architecture Standard 
both statically in the porting process as well as dynamically in its execution. The WFCCN porting process including 
compilation and linking should perform most of the STRS OE static checks as well as STRS application static 
checks. Linking WFCCN demonstrates the existence of the necessary run-time infrastructure to support STRS 
infrastructure' -provided and STRS application-provided APIs. 

The WFCCN execution performs many of the dynamic checks. The dynamic tests may be performed individually 
by APP_RunTest except for the one that tests STRS_RunTest with a target of WFCCN, which would cause an 
infinite loop. Any of the tests may be performed by APP_Start by specifying the appropriate value of 
STARTTESTS shown in Table 17. APPStart may call each APPRunTest except for the one that tests 
STRS_Start with a target of WFCCN, which would cause an infinite loop. The dynamic tests executed by 
APP RunTest are shown in Table 18. When the value of the variable named START TESTS is “YES”, APP Start 
performs all the tests shown in Table 18 in test ID order. Some of the tests with complex dependencies may return 
errors without generating a non-conformance. The test ID values shown in Table 18 assume that 
STRSTESTSTATUS is zero and that STRSTESTUSERBASE is one, as defined in GRC’s reference 
implementation. If that is not the case, zero would be replaced by the value of STRS TEST STATUS, one 
would be replaced by the value of STRS_TEST_USER_BASE, two would be replaced by the value of 
STRS_TEST_USER_BASE+1, etc. Note that there is one method missing from this list because it is not tested 
independently. STRSFileGetStreamPointer is tested when STRS FileOpen is tested. STRSFileGetStreamPointer 
can only be tested when the file is open. 

The step-by-step procedure for performing these tests is shown in Table 6. A test operator should fill in the blank 
columns and additional information following the table to show compliance. 


Table 6 - STRS WFCCN Test Automated Procedure 


Step 

Require- 
ment ID 

Test Operator Action 

Expected Result 

Actual 

Result 

Pass 

or 

Fail 

1 


Find/obtain the OE compliance testing 
command and control application, WFCCN. 
The files are: 

CommandAndComDlianceADDlication.cDD 
and C o m m andAndComnlianceAnnlication.il 
which may be obtained in the TVL from the 
Subversion configuration management tool at 
directory WFCCN/ or the files may be found 
in the CoNNeCT eRoom at: 

CoNNeCT > Principal Investigator > STRS > 
Compliance > . Record the directory where 
the files are stored. 

WFCCN\ 

CommandAndComplianceAp 

plication, cpp 

and 

WFCCN\ 

CommandAndComplianceAp 
plication. h 
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2 

STRS-89 

Find STRS infrastructure source files to test 
including STRS.h. Record the directory 
where the files are stored. 

vendorOE\STRS.h 



3 


Create a directoiy in GRC’s reference 
implementation for the compilation of 
WFCCN for the particular OE being tested in 
the same directory as 

CommandAndComplianceApplication.cpp 
and CommandAndComplianceApplication.h. 

WFCCN\myOE\ 



4 


Determine file names containing STRS 
infrastructure prototypes. Record the 
filenames and directory(s). This is facilitated 
by the last step of the previous section (section 
4.3.3, step 9). 

vendorOE\prototypeName.h 



5 


Create a file named STRS APIs.h containing 
a #include statement for each STRS 
infrastructure prototype file. This is 
facilitated by the last step of the previous 
section (section 4.3.3, step 9). 

WFCCN\myOE\STRS APIs, 
h 



6 


Edit the makefile or set up the IDE to compile 

CommandAndComplianceApplication.cpp, 

using 

CommandAndComplianceApplication.h; the 
prototypes, constants, stracts, and typedefs of 
the infrastructure to be tested; and the 
prototypes of step 5. 




7 

STRS- 19, 
STRS-40, 
STRS-41, 
STRS-42, 
STRS-43, 
STRS-44, 
STRS-45, 
STRS-46, 
STRS-47, 
STRS-48, 
STRS-49, 
STRS-50, 
STRS-51, 
STRS-52, 
STRS-53, 
STRS-54, 
STRS-55, 
STRS-56, 
STRS-57, 
STRS-58, 
STRS-59, 
STRS-61, 
STRS-62, 
STRS-63, 
STRS-64, 
STRS-65, 
STRS-66, 
STRS-67, 
STRS-68, 
STRS-69, 

Compile 

CommandAndComplianceApplication.cpp 
and analyze compilation outputs manually. 
Output errors and warnings indicate 
discrepancies between WFCCN and the 
infrastructure to be tested. Record errors, 
potential problems, and discrepancies. Note 
the associated requirement, if appropriate. 
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STRS-70, 

STRS-71, 

STRS-72, 

STRS-73, 

STRS-74, 

STRS-75, 

STRS-76, 

STRS-78, 

STRS-79, 

STRS-80, 

STRS-81, 

STRS-83, 

STRS-84, 

STRS-85, 

STRS-86, 

STRS-87, 

STRS-88, 

STRS-89, 

STRS-95 





8 


Determine whether WFCCN can be 
configured and controlled to perform dynamic 
testing. If WFCCN can be executed in the 
infrastructure to be tested, continue; 
otherwise, stop here. 

Usually WFCCN cannot be 
used to perform dynamic 
testing and the process stops 
here. 


NA 

9 

STRS-99, 
STRS- 100 

Create WFCCN configuration file in XML as 
described in documentation for the OE to be 
tested. Determine values for all items in 
Table 17 with START TESTS set to YES. 

WFCCN\myOE\ WFCCN. xm 

1 



10 

STRS- 104 

Transform to deployed form as described in 
documentation for OE to be tested. 

WF CCN\myOE\WF CCN.cfg 



11 


If needed by the OE, perform any additional 
modifications of 

CommandAndComplianceApplication.cpp, 
CommandAndComplianceApplication.h, and 
recompile. Need to recompile, for example, 
when WFCCN must be compiled as part of 
OS. 




12 


Start OE and WFCCN. Record errors, 
potential problems, and discrepancies. Note 
the associated requirement, if appropriate. 





Verification (Pass/fail): 


Comments: 


Test operator: 


Date: 


Product assurance: 


Date: 
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The Test Operator Action should provide enough detail to enable successful repetition of the test. 

1 . To halt or interrupt the test procedure in step 9, press Control-C. 

2. If WFCCN does not execute properly, the test operator may obtain additional data reflecting the execution 
of WFCCN using another IDE (e.g. Tornado) window. 

3. STRSAPIs.h is the only file that should be changed (in step 2) to reflect the specific names of the 
prototype files in the vendor’s OE. 

4. CommandAndComplianceApplication.cpp and CommandAndComplianceApplication.h may be changed 
(in step 8) if the infrastructure being tested dynamically has special start-up methods that must be 
implemented or certain restrictions pertaining to output and logging in the infrastructure being tested. 

4.3.5 Test Procedure for STRS Configuration File Testing 

An area of both inspection and semi-automated testing is the STRS configuration file in XML and its 

transformation. Although other products are available, GRC uses the COTS product XMLSpy to verify that the 

XML schema matches the XML data. This test procedure is described for XMLSpy since that is what GRC used. 

The step-by-step procedure for performing these tests is shown in Table 7. A test operator should fill in the blank 

columns and additional information following the table to show compliance. 


Table 7 - STRS Configuration Files Test Procedure 


Step 

Requirement 

ID 

Test Operator Action 

Expected 

Result 

Actual 

Result 

Pass 

or 

Fail 

1 

STRS- 100 

Find the STRS platform integrator’s pre-deployed 
application configuration file in XML. 




2 

STRS-101 

Verify that the pre-deployed application 

configuration file found in step 1 contains the 

following application attributes and default values: 

• Identification 

• Unique STRS handle name for the application 

• Class name (if applicable) 

• State after processing the configuration file 

• Required resources: memory in bytes or 
number of gates or logic elements 

• Configuration parameters containing the STRS 
handle, names of files, devices, queues, 
waveforms and services needed by the STRS 
application 

• Values and constraints for all operationally 
configurable parameters 

• Filename(s) of loadable images for resources 




3 

STRS-102 

Find the STRS platform provider’s XML schema to 
validate the format and data for pre-deployed STRS 
application configuration files, including the order 
of the tags, the number of occurrences of each tag, 
and the values or attributes. 




4 


Verify that the pre-deployed application 
configuration file found in step 1 contains a tag for 
an XMLSchema-instance. Verify that the name of 
the file matches the one found in step 4. An 
example for GRC’s referenced implementation is: 
<STRS 
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xmlns:xsi="http://www. w3.org/2001/XMLSchema- 
instance" 

xsi:noNamespaceSchemaLocation="STRS.xsd"> 




5 


Star 

D 

t up Altova XMLSpy. 

XMLSpy 

window 

appears 



6 


Using file menu, open the pre-deployed 
configuration files in XML and corresponding 
schema definition files (XSD) using XMLSpy. 

XMLSpy 
window 
displays files 
(tabbed). 




>3 Altova XMLSpy 


File 

D 

| Edit Project Authentic DB Co 
New... Ctrl+N 

||3J Open... Ctrl+0 | 

7 



Jsing view menu, change to t 
dready there. 

View Browser Tools Window Help 

ext view, if not 

XMLSpy 
window 
displays text. 



fv] Jext View 

8 



3res 

¥ 

ck well-formedness by clicking on icon or 
sing F7. 

neck well-formedness(F7) 

XMLSpy 
message 
window 
displays 
check mark 
in yellow 
circle 0 and 
text: File X 
is well- 
formed. 



9 


1 

^erl 

F8. 

¥_ 

K 

orm validation by clicking on icon or pressing 
alidate(F8) 

XMLSpy 
message 
window 
displays 
check mark 
in green 
circle © and 
text: File X 
is valid. 



10 

STRS-98 

Find the STRS platform provider’s documentation 
of the necessary platform information to develop a 
pre-deployed application configuration file in XML 
(including a sample file). 




11 

STRS-99 

Find the STRS application developer 1 s 
documentation of the necessary application 
information to develop a pre-deployed application 
configuration file in XML. 




12 

STRS-103 

Use the STRS platform provider’s tools to 
transform pre-deployed application configuration 
file in XML into a deployed application 
configuration file. 

Check the pre-deployed application configuration 
file found in step 1 for an xml-stylesheet to define a 
transformation. 
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13 

STRS- 104 

Find the STRS platform integrator’s deployed 
STRS application configuration file for the STRS 
infrastructure. 





Verification (Pass/fail): 


Comments: 


Test operator: Date: 

Product assurance: Date: 


4.3.6 Test Procedure for STRS Application Manual Code Testing 

The automated testing described above leaves many areas untested. Manual code compliance includes inspection of 
application artifacts to verify: 

a. The usage of infrastructure' -provided interfaces; i.e., that the only external interfaces called by the STRS 

application are the STRS infrastructure-provided APIs and allowed POSIX PSE51 APIs (STRS-10, STRS-91). 

b. That the application implements the appropriate functionality and exhibits proper state transition behavior. 

c. That the application has the appropriate C++ class hierarchy, if written in C++. 

d. That the application software artifacts have been submitted to the STRS application repository (STRS-12). 

e. FPGA wrapper is provided if the platform has an FPGA (STRS-14). 

The step-by-step procedure for performing these tests is shown in Table 8. A test operator should fill in the blank 
columns and additional information following the table to show compliance. 


Table 8 - STRS Application Test Manual Procedure 


Step 

Requirement 

ID 

Test Operator Action 

Expected Result 

Actual Result 

Pass or 
Fail 

1 

STRS-10, 

STRS-91 

Verify that the only external 
interfaces called by the STRS 
application are the STRS 
infrastructure' -provided APIs and 
allowed POSIX PSE51 APIs. 




2 

STRS-12 

Find application development 
artifacts submitted to the NASA 
STRS Repository. Find appropriate 
license agreements. Verify that the 
application development artifacts 
include the following: 

• High level system or 
component software model 

• Documentation of application 
firmware external interfaces 
(e.g. signal names and 
descriptions, signal polarity 
and format, timing constraints 
of signals) 

• Documentation of STRS 
application behavior 

• Application function sources 
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(e.g. C, C++, header files, 
VHDL, Verilog) 

• Application libraries, if 
applicable (e.g. EDIF, DLL) 

• Documentation of application 
development environment and 
tool suite 

• Test plan and results 
documentation 

• Identification of Flight 
Software Development 
Standards used 




3 

STRS- 14 

Verify that FPGA wrapper is 
provided (if platform has FPGA) 




4 

STRS-16 

Determine whether the STRS 
Application-provided Application 
Control API is implemented using 
C or C++. 




5 

STRS-22 

If the STRS Application-provided 
Application Control API is 
implemented in C++, verify that 
the STRS application class is 
derived from the 
STRS_ApplicationControl base 
class. 




6 

STRS-25 

If the STRS Application-provided 
Application Control API is 
implemented in C++ AND the 
STRS application provides the 
APP Write method, verify that the 
STRS application class is derived 
from the STRS Sink base class. 




7 

STRS-28 

If the STRS Application-provided 
Application Control API is 
implemented in C++ AND the 
STRS application provides the 
APP Read method, verify that the 
STRS application class is derived 
from the STRS Source base class. 




8 

STRS-60 

Verify that the STRS applications 
use the STRS infrastructure Device 
Control methods to control the 
STRS Devices. 




9 

STRS-77 

Verify that the STRS applications 
use the STRS Infrastructure 
Messaging methods to send 
messages between applications 
and/or the infrastructure with a 
single target handle ID. 




10 

STRS-82 

Verify that any portion of the 
STRS Applications on the GPP 
needing time control uses the STRS 
Infrastructure Time Control 
methods to access the hardware 
and software timers. 
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11 

STRS-97 

Verify that any STRS application 
uses the STRS Log and 
STRS_Write methods to send 
STRS telemetry set information to 
the external system. 





Verification (Pass/fail): 


Comments: 


Test operator: Date: 

Product assurance: Date: 


4.3.7 Test Procedure for STRS Infrastructure Manual Code Testing 

The automated testing described above leaves many areas of the infrastructure untested. Additional compliance 
testing for the STRS OE may include: 

a. Provides POSIX 1003.13 PSE51 conformant OS or a POSIX abstraction layer. Very small platforms can 
provide the minimum subset of PSE51 required to support mission waveforms (with a waiver) (STRS-90) 

b. Verify that the STRS predefined data for typedefs, constants, and structs is provided in header file STRS.h 
(STRS-89) 

c. Provides necessary header files for application developers (STRS-20, STRS-21, STRS-24, STRS-27) 

The step-by-step procedure for performing these tests is shown in Table 9. A test operator should fill in the blank 
columns and additional information following the table to show compliance. 


Table 9 - STRS Infrastructure Test Manual Procedure 


Step 

Require- 
ment ID 

Test Operator Action 

Expected Result 

Actual 

Result 

Pass or 
Fail 

1 

STRS-18 

Verify that the STRS Operating 
Environment supports C or C++ language 
interfaces for the STRS Application- 
provided Application Control API at 
compile-time. 




2 

STRS-21 

Verify that the STRS platform provider 
supplied an “STRS ApplicationControl.h” 
that contains the method prototypes and, 
for C++, the class definition for the base 
class STRS ApplicationControl. 




3 

STRS-24 

Verify that the STRS platform provider 
supplied an “STRS Sink.h” that contains 
the method prototypes and, for C++, the 
class definition for the base class 
STRS Sink. 




4 

STRS-27 

Verify that the STRS platform provider 
supplied an “STRS Source.h” that 
contains the method prototypes and, for 
C++, the class definition for the base class 
STRS Source. 
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5 

STRS-90 

Verify that the STRS Operating 
Environment supplies the interfaces 
described in POSIX IEEE Standard 
1003.13-2003 profile PSE51. 




6 

STRS-96 

Verify that the STRS infrastructure uses 
the STRS Query ; method to service 
external system requests for information 
from an STRS application. 





Verification (Pass/fail): 


Comments: 


Test operator: Date: 

Product assurance: Date: 
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APPENDIX A — Glossary and Acronyms 

This section should include an alphabetical listing of all acronyms, abbreviations, and their meanings as 
used in this document and a list of terms and definitions needed to understand this document. 

A.l Definitions 

The glossary in Table 10 contains an alphabetized list of definitions for special terms used in the 
document; that is, the terms are used in a sense that differs from or is more specific than the common 
usage for such terms. STRS-specific terms are defined in NASA/TM-2008-2 15445. 


Table 10 - Glossary 


Term 

Definition 

Test case 

Same as a test procedure. 

Test procedure 

A set of conditions or variables under which a tester will determine 
whether an application or software system is working correctly or not. 
Also referred to as test scripts. 

Test suite 

A collection of test procedures. 
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A.2 Acronyms 

Table 1 1 contains the definitions for the abbreviations and acronyms used in this document. 


Table 11 - Acronyms 


Acronym 

Definition 

API 

Application Programmers Interface 

BER 

Bit Error Rate 

BIT 

Built-In Test 

BPS 

Bits Per Second 

FPGA 

Field-Programmable Gate Array 

HAL 

Hardware Abstraction Layer 

HID 

Hardware Interface Description 

ID 

Identifier 

OE 

Operating Environment = OS & STRS Infrastructure 

OS 

Operating System 

POSIX 

Portable Operating System Interface for Unix 

SDR 

Software Defined Radio 

STRS 

Space Telecommunications Radio System 

TVL 

Technology Verification Lab at GRC 

WDT 

Watchdog Timer 

WF 

Waveform = STRS application 

WFCCN 

Command and Control Application 

XML 

Extensible Markup Language 

XSD 

XML Schema Definition 
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APPENDIX B— Traceability to SWE-114 of NPR 7150.2A 


Table 12 - Traceability to SWE-114 of 7150. 2A 


Document Section(s) 

SWE-114 Requirement 


The STRS Compliance Test Procedures shall contain: 
[SWE-114] 

3.0 Test Configuration 

a. Test preparations, including hardware and software. 

4.0 Test Descriptions 

b. Test descriptions, including: 

4.3 STRS Compliance Testing 

1. Test identifier. 

4.1 Requirements Being Tested, Table 19, 
Table 4, Table 5, 

Table 6, Table 7, 

Table 8, Table 9 

2. System or CSCI requirements addressed by the 
test case. 

4.3.1 Prerequisite Conditions, Assumptions, 
and Constraints 

3. Prerequisite conditions. 

Table 4, Table 5, 
Table 6, Table 7, 
Table 8, Table 9 

4. Test input. 

4.2 Test Instructions, Table 4, Table 5, 
Table 6, Table 7, Table 8, Table 9 

5. Instructions for conducting procedure. 

Table 4, Table 5, 
Table 6, Table 7, 
Table 8, Table 9 

6. Expected test results, including assumptions and 
constraints. 

Table 4, Table 5, 
Table 6, Table 7, 
Table 8, Table 9 

7. Criteria for evaluating results. 

Table 19 

c. Requirements traceability. 

3.0 Test Configuration 

d. Identification of test configuration. 
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APPENDIX C — Application Compliance Testing Tables 


Table 13 is an example of the execution of the application compliance test using ComplianceTool.sh as described in 
section 4.3.2 for the preliminary GRC/GSFC waveform in directory WFgsfc. Summary information is displayed 
during execution of the script to indicate its progress and show the number of errors. 

Table 13 - Compliance Script Execution 

Enter directory or source fde to test for STRS compliance (or Q, C, or ?): WFgsfc 
Entered: WFgsfc 
Process directory WFgsfc 
Found 3 fdes to test. 

APP_: 19 

STRS_: 131 

2 POSIX, 0 deprecated, and 0 QuicComm method errors. 

0 APP methods missing and 9 APP methods found correctly and 0 extra APP methods. 

1 non-standard APP method definitions. 

131 STRS methods and 0 extra STRS methods. 

Need to address 2 errors. 

POSIX strtok not allowed (consider strtok r). 


2 POSIX, 0 deprecated, and 0 QuicComm method errors. 

0 APP methods missing and 9 APP methods found correctly and 0 extra APP methods. 

1 non-standard APP method definitions. 

131 STRS methods and 0 extra STRS methods. 

Need to address 2 errors. 


Table 14 is an example of the output of the application compliance test using ComplianceTool.sh as described in 
section 4.3.2 saved as a web page so that color and formatting can be shown. From either type of output, one can 
see that there were 2 POSIX method calls that are not allowed and there were 0 deprecated method calls used for a 
total of 2 definite problems to address. The extra or non-standard methods used are probably not a problem but 
rather an artifact of the simple method of testing that is being used. In the example output below, the missing STRS 
include file was STRS.h which was in a #include within a #include file. This is a potential portability issue but not 
currently a non-conformance. The web page looks like: 
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Table 14 - Compliance Script Web Page Output 


Directory WFgsfc/src 


• Process directory WFgsfc/src 


Occurrences 

Item Examined 

2 

POSIX methods not allowed 

0 

Deprecated methods 

0 

QuicComm methods 

0 

Missing STRSTESTSTATUS from APP RunTest 

9 

APP required methods found out of 9 

0 

APP required methods missing 

1 

Non-standard APP method definitions or invocations 

0 

Extra APP methods 

131 

STRS methods 

10 

Distinct STRS methods out of 43 

0 

Extra STRS methods 

1 

Missing STRS include files 

2 

Need to address 2 errors 
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APPENDIX D — Infrastructure Compliance Testing Tables 

Table 15 is an example of the execution of the infrastructure compliance test using ComplianceToolOE.sh as 
described in section 4.3.3 for GRC’s reference implementation. Summary information is displayed to show the 
number of errors and the progress of the execution of the script. 

Table 15 - OE Compliance Script Execution 

Enter directory or STRS.h source file to test for STRS OE source compliance 

(or Q): STRS_ReferenceImplementation/OE 

Entered: STRS_ReferenceImplementation/OE 

Process directory STRS_ReferenceImplementation/OE 

Found 4 files to test. 

Process: STRS.h 
Skip: stdlib.h 
Process: Property. h 
Process: Properties. h 

0 typedefs missing and 24 typedefs found correctly. 

0 constants missing and 26 constants found correctly. 

0 structs missing and 2 structs found correctly. 

0 files missing and 4 files found correctly out of 4. 

Need to address 0 errors. 


Table 16 is an example of the output of the application compliance test using ComplianceToolOE.sh as described in 
section 4.3.3. The results are saved as a web page so that color and formatting can be shown. From either type of 
output, one can see that there are no errors left in the NASA GRC STRS reference implementation. The web page 
looks like: 

Table 16 - OE Compliance Script Web Page Output 


Directory STRS_ReferenceImplementation/OE 

• Process directory STRS_ReferenceImplementation/OE 


Occurrences 

Item Examined 

0 typedefs missing 

24 typedefs found correctly 

0 

constants missing 

26 

constants found correctly 

0 

structs missing 

~2 

structs found correctly 

0 

files missing 

4 files found correctly 


The web page also displays a list of #include statements needed for the STRS infrastructure-provided methods. This 
list may be used to create STRS APIs.h in section 4.3.4 (WFCCN). 


NASA/TM— 20 11-217266 


32 






Space Telecommunications Radio System (STRS) Compliance Testing 

Date: May 31,2011 

Document No.: STRS-ATP-00001 

Page 33 of 46 


APPENDIX E — Infrastructure Compliance Testing by WFCCN Tables 

Table 17 shows the properties to be configured by WFCCN used to test for dynamic compliance as described in 
section 4.3.4. 


Table 17 - WFCCN Configurable Data 


Item 

Name 

Description 

1 

ABORTNAME 

Value is handle name of application to abort. This should not be 
WFCCN. 

2 

ACCESS 

Value for file open may be: READ, WRITE, BOTH, or APPEND. 

3 

DEVICELOAD 

Value is file name to be loaded into Device. This is usually a bit file 
produced as the result of VHDL processing. 

4 

DEVICE NAME 

Value is handle name of Device. 

5 

FILE NAME 

Value is file or directory name. 

6 

FILE RENAME 

Value is file name to remove or rename to. 

7 

FILE TYPE 

Value for file open may be: BINARY or TEXT. 

8 

HANDLE NAME 

Value is a handle name to look up for STRS HandleRequest. 

9 

IO DATA 

Value is data for testing STRS Log, STRS Write, and STRS Read. 

10 

MSG 

Value is data for testing for APP Read. 

11 

PRIORITY 

Value of priority when creating a queue may be: LOW, MEDIUM, or 
HIGH. 

12 

QUEUE NAME 

Value is name of queue to create. 

13 

QUEUE TARGET 

Value is name of subscriber queue. 

14 

QUEUE TYPE 

Value of queue type may be: SIMPLE or PUBSUB. 

15 

READ NAME 

Value is handle name of target for STRS Read. 

16 

RELEASE NAME 

Value is handle name of application to release. 

17 

STARTTESTS 

Value is YES to start all APP RunTests in APP Start, NO to wait 
and start individual tests when requested, or an individual test ID 
number as shown in Table 18. 

18 

TESTID 

Value is the appropriate test ID number for testing STRS RunTest or 
STRS GroundTest. 

19 

TIMER DELTA 

Value is timer offset from base used by STRS SetTime. 

20 

TIMERKIND 

Value is kind of timer used for testing STRS GetTime and 
STRS SetTime. 

21 

TIMER NAME 

Value is handle name of timer. 

22 

TIMER REF 

Value is kind of reference timer to synchronize to. 

23 

TIMER TGT 

Value is kind of timer to synchronize. 

24 

USE 

Value is handle name of target. 

25 

WRITENAME 

Value is handle name of target for STRS Write. 


Table 1 8 associates a test ID with a test of each infrastructure' -provided method and describes the data that is 
configured to run the test. These tests are usually done multiple times; once en mass by configuring 
START_TESTS=YES and then individually as needed. 
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Table 18 - WFCCN tests in APP RunTest 


Test ID 

Test API or other 

Description 

0 

STRS TEST STATUS 

Obtains state information. 

1 

STRS IsOK 

Verifies for each type of error that the return value is valid. 

2 

STRSGetErrorQueue 

Verifies for each matching constant error and error queue 
that the handle ID of the error queue equals 
STRS GetErrorQueue(error). 

3 

STRS InstantiateApp 

Configuration file is value(FILE NAME). 

4 

STRSC onfigure 

Target to configure is value(USE) with properties given for 
APP RunTest. 

5 

STRSQuery 

Target to query is value(USE) and property names are those 
given for APP RunTest, if there are any defined; otherwise, 
no property names are given but the STRS Properties 
structure contains room for many to be queried. 

6 

STRSRunTest 

Target to test is value(USE) with test ID specified as 
value(TEST ID) and properties given for APP RunTest. 

7 

STRSGroundTest 

Target to test is value(USE) with test ID specified as 
value(TEST ID) and properties given for APP RunTest. 

8 

STRS Initialize 

Target to initialize is value(USE). 

9 

STRS Start 

Target to start is value(USE). 

10 

STRSDeviceLoad 

Target Device to load is value(DEVICENAME) with file 
specified as value(DEVICE LOAD). 

11 

STRS DeviceOpen 

Target Device to open is value(DEVICE NAME). 

12 

STRS DeviceReset 

Target Device to reset is value(DEVICE NAME). 

13 

STRS DeviceStart 

Target Device to start is value(DEVICE NAME). 

14 

STRSFileGetFreeSpace 

Target file system (if needed) is value(FILE NAME). 

15 

STRSFileOpen 

Target file is value(FILE NAME), file access is 
value(ACCESS), and file type is value(FILE TYPE). 

16 

STRSQueueCreate 

Name of queue to create is value(QUEUE NAME), type of 
queue is value(QUEUE TYPE), and priority of queue is 
value(PRIORITY). 

17 

STRSRegister 

Target to register as a publisher is value(QUEUE NAME). 
Target to register as a subscriber is 
value(QUEUETARGET). 

18 

STRSLog 

Target to write log to is value(USE) and data is 
value(IO DATA). 

19 

STRSWrite 

Target to write is value(WRITE NAME) and data is 
value(IO DATA). 

20 

STRSRead 

Target to read is value(READ NAME) and size of data is 
determined from value(IO DATA). 

21 

STRSUnregister 

Target to unregister is value(QUEUE NAME) and 
subscriber is value(QUEUE TARGET). 

22 

STRS QueueDelete 

Target to delete is value(QUEUE NAME). 

23 

STRS FileClose 

Target file to close is value(FILE NAME). 
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Test ID 

Test API or other 

Description 

24 

STRS FileGetSize 

Target file is value(FILE NAME). 

25 

STRS FileRename 

File to rename is value(FILE NAME) and file name to 
rename it to is value(FILE RENAME). 

26 

STRS FileRemove 

Target file is value(FILERENAME). 

27 

STRS DeviceStop 

Target Device to stop is value(DEVICE NAME). 

28 

STRS DeviceFlush 

Target Device to flush is value(DEVICE NAME). 

29 

STRS DeviceClose 

Target Device to close is value(DEVICE NAME). 

30 

STRS SetlSR 

Target to set ISR is value(DEVICE NAME). 

31 

STRS DeviceUnload 

Target Device to unload is value(DEVICE NAME). 

32 

STRS Stop 

Target to stop is value(USE). 

33 

STRS FlandleRequest 

Obtains the handle ID for value(FIANDLE NAME). 

34 

STRS ReleaseObject 

Target to release is value(RELEASE NAME). 

35 

STRS AbortApp 

Target to abort is value(ABORT NAME). 

36 

STRSGetNanoseconds 

Verifies a constant number of nanoseconds set in an 
STRS Time Warp item. 

37 

STRSGetSeconds 

Verifies a constant number of seconds set in an 
STRS Time Warp item. 

38 

STRS GetTimeWarp 

Verifies constants set in an STRS TimeWarp item. 

39 

STRSGetTime 

Target to get time from is value(TIMER NAME) and kind 
of timer is value(TIMER KIND). 

40 

STRSSetTime 

Target to set time is value(TIMER NAME), kind of timer 
is value(TIMER KIND), and timer offset in seconds is 
value(TIMER DELTA). 

41 

STRSSynch 

Target to synchronize is value(TIMER NAME), kind of 
timer to synchronize is value(TIMER TGT) and kind of 
timer to use as reference is value(TIMER REF). 

42 

Predefined data 

This tests whether the constants, typedefs, and structs may 
be used consistently. 
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APPENDIX F— COMPLIANCE TESTING BY REQUIREMENT 

The following Table 19 shows which requirements are tested by STRS using manual inspection, observation, 
scripts, or porting WFCCN as described in previous sections. Table 19 shows whether the requirement applies to 
the OE, the platform, or the STRS application. The “OK?” column is added to use the table as a checklist. The 
table numbers that appear within Table 19 are references to the tables in the STRS Architecture Standard. 


Table 19 - Requirements Testing 


Requirements 

Description 

OE/App 

Tested 

OK? 

STRS-1 

An STRS platform shall have a known state after 
completion of the power-up process. 

OE 

Observe 


STRS-2 

The STRS Operating Environment shall provide access to 
platform module’s diagnostic information via the STRS 
APIs. 

OE 

Observe 


STRS-3 

Self diagnostic and fault detection data of a module shall be 
accessible to the STRS Operating Environment for 
collection. 

OE 

Observe 


STRS-4 

The STRS platform provider shall describe in the HID 
document, the behavior and capability of each major 
functional device or resource available for use by 
waveforms, services, or other applications (e.g. FPGA, 
GPP, DSP, memory), noting any operational limitations. 

Platform 

Inspect 

document 


STRS-5 

The STRS platform provider shall describe in the HID 
document, the reconfigurability behavior and capability of 
each reconfigurable component. 

Platform 

Inspect 

document 


STRS-6 

The STRS platform provider shall describe in the HID 
document, the behavior and performance of the RF modular 
component(s). 

Platform 

Inspect 

document 


STRS-7 

The STRS platform provider shall describe in the HID 
document, the interfaces that are provided to and from each 
modular component of the radio platform. 

Platform 

Inspect 

document 


STRS-8 

The STRS platform provider shall describe in the HID 
document, the control, telemetry, and data mechanisms of 
each modular component (i.e. how to program or control 
each modular component of the platform, and how to use or 
access each device or software component, noting any 
proprietary aspects). 

Platform 

Inspect 

document 


STRS-9 

The STRS platform provider shall describe in the HID 
document, the behavior and performance of any power 
supply or power converter modular component(s). 

Platform 

Inspect 

document 


STRS- 10 

An STRS application shall use the infrastructure STRS API 
and POSIX API for access to platform resources. 

App 

Script & 
Inspect 


STRS-1 1 

The STRS infrastructure shall use the STRS Platform HAL 
APIs to communicate with application components on the 
platform specialized hardware via the physical interface 
defined by the platform provider. 

OE 

No 
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Requirements 

Description 

OE/App 

Tested 

OK? 

STRS- 12 

Application development artifacts shall be submitted to the 
NASA STRS Repository. The use will be subject to the 
appropriate license agreements. The application 
development artifacts shall include, as a minimum, the 
following: 

• High level system or component software model 

• Documentation of application firmware external 
interfaces (e.g. signal names and descriptions, signal 
polarity and format, timing constraints of signals) 

• Documentation of STRS application behavior 

• Application function sources (e.g. C, C++, header files, 
VHDL, Verilog) 

• Application libraries, if applicable (e.g. EDIF, DLL) 

• Documentation of application development 
environment and tool suite 

• Test plan and results documentation 

• Identification of Flight Software Development 
Standards used 

App 

Inspect 


STRS- 13 

If the STRS application has a component resident in an 
SPM (e.g. FGPA firmware), then it shall accept 
configuration and control commands from the STRS 
Operating Environment. 

App 

Observe 


STRS- 14 

The STRS SPM developer shall provide a platform specific 
wrapper for each user-programmable FPGA on the SPM, 
which performs, as a minimum, the following functions 

• Provides an interface for command and data from the 
GPM to the waveform application 

• Provides the platform specific pinout for the 
application developer. This may be a complete 
abstraction of the actual FPGA pinouts with only 
waveform application signal names provided. 

Platform 

Inspect 
document & 
code 


STRS- 15 

The STRS SPM developer shall provide documentation on 
the firmware interfaces of the platform specific wrapper for 
each user-programmable FPGA on the SPM, which 
describe, as a minimum, the following 

• Signal names and descriptions 

• Signal polarity and format 

• Signal timing constraints of all signals 

• Clock generation and synchronization methods 

• Signal registering methods 

• Identification of development tool set used 

Platform 

Inspect 

document 


STRS- 16 

The STRS Application-provided Application Control API 
shall be implemented using C or C++. 

App 

Inspect 


STRS- 17 

The STRS infrastructure shall use the STRS Application- 
provided Application Control API to control STRS 
applications. 

OE 

Script 
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Requirements 

Description 

OE/App 

Tested 

OK? 

STRS- 18 

The STRS Operating Environment shall support C or C++ 
language interfaces for the STRS Application-provided 
Application Control API at compile-time. 

OE 

Inspect 


STRS- 19 

The STRS Operating Environment shall support C or C++ 
language interfaces for the STRS Application-provided 
Application Control API at run-time. 

OE 

WFCCN 


STRS-20 

Each STRS application shall contain: 
#include "STRS ApplicationControl.h" 

App 

Script 


STRS-21 

The STRS platform provider shall provide an 
“STRS ApplicationControl.h” that contains the method 
prototypes and, for C++, the class definition for the base 
class STRS ApplicationControl. 

OE 

Inspect 


STRS-22 

If the STRS Application-provided Application Control API 
is implemented in C++, the STRS application class shall be 
derived from the STRS ApplicationControl base class. 

App 

Inspect 


STRS-23 

If the STRS application provides the APP Write method, 
the STRS application shall contain 
include "STRS Sink.h" 

App 

Script 


STRS-24 

The STRS platform provider shall provide an 

“STRS Sink.h” that contains the method prototypes and, 

for C++, the class definition for the base class STRS Sink. 

OE 

Inspect 


STRS-25 

If the STRS Application-provided Application Control API 
is implemented in C++ AND the STRS application provides 
the APP Write method, the STRS application class shall be 
derived from the STRS Sink base class. 

App 

Inspect 


STRS-26 

If the STRS application provides the APP Read method, 
the STRS application shall contain 
#inclnde "STRS Source. h" 

App 

Script 


STRS-27 

The STRS platform provider shall provide an 
“STRS Source.h” that contains the method prototypes and, 
for C++, the class definition for the base class 
STRS Source. 

OE 

Inspect 


STRS-28 

If the STRS Application-provided Application Control API 
is implemented in C++ AND the STRS application provides 
the APP Read method, the STRS application class shall be 
derived from the STRS Source base class. 

App 

Inspect 


STRS-29 

Each STRS application shall contain a callable 
APP Configure method as described in Table 8-3. 

App 

Script 


STRS-30 

Each STRS application shall contain a callable 
APP GroundTest method as described in Table 8-4. 

App 

Script 


STRS-31 

Each STRS application shall contain a callable 
APP Initialize method as described in Table 8-5. 

App 

Script 


STRS-32 

Each STRS application shall contain a callable 
APP Instance method as described in Table 8-6. 

App 

Script 
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Requirements 

Description 

OE/App 

Tested 

OK? 

STRS-33 

Each STRS application shall contain a callable APP Quay 
method as described in Table 8-7. 

App 

Script 


STRS-34 

If the STRS application provides data to the infrastructure, 
then the STRS application shall contain a callable 
APP Read method as described in Table 8-8. 

App 

Script 


STRS-35 

Each STRS application shall contain a callable 
APP ReleaseObject method as described in Table 8-9. 

App 

Script 


STRS-36 

Each STRS application shall contain a callable 
APP RunTest method as described in Table 8-10. 

App 

Script 


STRS-37 

Each STRS application shall contain a callable APP Start 
method as described in Table 8-11. 

App 

Script 


STRS-38 

Each STRS application shall contain a callable APP Stop 
method as described in Table 8-12. 

App 

Script 


STRS-39 

If the STRS application receives data from the 
infrastructure, then the STRS application shall contain a 
callable APP Write method as described in Table 8-13. 

App 

Script 


STRS-40 

The STRS infrastructure shall contain a callable 
STRS Configure method as described in Table 8-14. 

OE 

WFCCN 


STRS-41 

The STRS infrastructure shall contain a callable 
STRS GroundTest method as described in Table 8-15. 

OE 

WFCCN 


STRS-42 

The STRS infrastructure shall contain a callable 
STRS Initialize method as described in Table 8-16. 

OE 

WFCCN 


STRS-43 

The STRS infrastructure shall contain a callable 
STRS Query method as described in Table 8-17. 

OE 

WFCCN 


STRS-44 

The STRS infrastructure shall contain a callable 
STRS ReleaseObject method as described in Table 8-18. 

OE 

WFCCN 


STRS-45 

The STRS infrastructure shall contain a callable 
STRS RunTest method as described in Table 8-19. 

OE 

WFCCN 


STRS-46 

The STRS infrastructure shall contain a callable STRS Start 
method as described in Table 8-20. 

OE 

WFCCN 


STRS-47 

The STRS infrastructure shall contain a callable STRS Stop 
method as described in Table 8-21. 

OE 

WFCCN 


STRS-48 

The STRS infrastructure shall contain a callable 
STRS AbortApp method as described in Table 8-22. 

OE 

WFCCN 


STRS-49 

The STRS infrastructure shall contain a callable 
STRS GetErrorQueue method as described in Table 8-23. 

OE 

WFCCN 


STRS-50 

The STRS infrastructure shall contain a callable 
STRS HandleRequest method as described in Table 8-24. 

OE 

WFCCN 


STRS-51 

The STRS infrastructure shall contain a callable 
STRS InstantiateApp method as described in Table 8-25. 

OE 

WFCCN 


STRS-52 

The STRS infrastructure shall contain a callable 
STRS IsOK method as described in Table 8-26. 

OE 

WFCCN 


STRS-53 

The STRS infrastructure shall contain a callable STRS Log 
method as described in Table 8-27. 

OE 

WFCCN 
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Requirements 

Description 

OE/App 

Tested 

OK? 

STRS-54 

When an STRS application has a non-fatal error, the STRS 
application shall use the STRS Log method (Table 8-27) 
with a target handle ID of constant 
STRS ERROR QUEUE. 

App 

WFCCN 


STRS-55 

When an STRS application has a fatal error, the STRS 
application shall use the STRS Log method (Table 8-27) 
with a target handle ID of constant 
STRS FATAL QUEUE. 

App 

WFCCN 


STRS-56 

When an STRS application has a warning condition, the 
STRS application shall use the STRS Log method (Table 8- 
27) with a target handle ID of constant 
STRS WARNING QUEUE. 

App 

WFCCN 


STRS-57 

When an STRS application needs to send telemetry, the 
STRS application shall use the STRS Log method (Table 8- 
27) with a target handle ID of constant 
STRS TELEMETRY QUEUE. 

App 

WFCCN 


STRS-58 

The STRS infrastructure shall contain a callable 
STRS Write method as described in Table 8-28. 

OE 

WFCCN 


STRS-59 

The STRS infrastructure shall contain a callable STRS Read 
method as described in Table 8-29. 

OE 

WFCCN 


STRS-60 

The STRS applications shall use the STRS infrastructure 
Device Control methods to control the STRS Devices. 

OE 

Inspect 


STRS-61 

The STRS infrastructure shall contain a callable 
STRS DeviceClose method as described in Table 8-30. 

OE 

WFCCN 


STRS-62 

The STRS infrastructure shall contain a callable 
STRS DeviceFlush method as described in Table 8-31. 

OE 

WFCCN 


STRS-63 

The STRS infrastructure shall contain a callable 
STRS DeviceLoad method as described in Table 8-32. 

OE 

WFCCN 


STRS-64 

The STRS infrastructure shall contain a callable 
STRS DeviceOpen method as described in Table 8-33. 

OE 

WFCCN 


STRS-65 

The STRS infrastructure shall contain a callable 
STRS DeviceReset method as described in Table 8-34. 

OE 

WFCCN 


STRS-66 

The STRS infrastructure shall contain a callable STRS 
DeviceStart method as described in Table 8-35. 

OE 

WFCCN 


STRS-67 

The STRS infrastructure shall contain a callable STRS 
DeviceStop method as described in Table 8-36. 

OE 

WFCCN 


STRS-68 

The STRS infrastructure shall contain a callable 
STRS DeviceUnload method as described in Table 8-37. 

OE 

WFCCN 


STRS-69 

The STRS infrastructure shall contain a callable 
STRS SetlSR method as described in Table 8-38. 

OE 

WFCCN 


STRS-70 

The STRS infrastructure shall contain a callable 
STRS FileClose method as described in Table 8-39. 

OE 

WFCCN 


STRS-71 

The STRS infrastructure shall contain a callable 

STRS FileGetFreeSpace method as described in Table 8- 

40. 

OE 

WFCCN 


STRS-72 

The STRS infrastructure shall contain a callable 
STRS FileGetSize method as described in Table 8-41. 

OE 

WFCCN 


STRS-73 

The STRS infrastructure shall contain a callable 

STRS FileGetStreamPointer method as described in Table 

8-42. 

OE 

WFCCN 


STRS-74 

The STRS infrastructure shall contain a callable 
STRS FileOpen method as described in Table 8-43. 

OE 

WFCCN 


STRS-75 

The STRS infrastructure shall contain a callable 

OE 

WFCCN 
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Requirements 

Description 

OE/App 

Tested 

OK? 


STRS FileRemove method as described in Table 8-44. 




STRS-76 

The STRS infrastructure shall contain a callable 
STRS FileRename method as described in Table 8-45. 

OE 

WFCCN 


STRS-77 

The STRS applications shall use the STRS Infrastructure 
Messaging methods to send messages between applications 
and/or the infrastructure with a single target handle ID. 

App 

Inspect 


STRS-78 

The STRS infrastructure shall contain a callable 
STRS QueueCreate method as described in Table 8-46. 

OE 

WFCCN 


STRS-79 

The STRS infrastructure shall contain a callable 
STRS QueueDelete method as described in Table 8-47. 

OE 

WFCCN 


STRS-80 

The STRS infrastructure shall contain a callable 
STRS Register method as described in Table 8-48. 

OE 

WFCCN 


STRS-81 

The STRS infrastructure shall contain a callable 
STRS Unregister method as described in Table 8-49. 

OE 

WFCCN 


STRS-82 

Any portion of the STRS Applications on the GPP needing 
time control shall use the STRS Infrastructure Time Control 
methods to access the hardware and software timers. 

App 

Inspect 


STRS-83 

The STRS infrastructure shall contain a callable 

STRS GetNanoseconds method as described in Table 8-50. 

OE 

WFCCN 


STRS-84 

The STRS infrastructure shall contain a callable 
STRS GetSeconds method as described in Table 8-51. 

OE 

WFCCN 


STRS-85 

The STRS infrastructure shall contain a callable 
STRS GetTime method as described in Table 8-52. 

OE 

WFCCN 


STRS-86 

The STRS infrastructure shall contain a callable 
STRS GetTimewarp method as described in Table 8-53. 

OE 

WFCCN 


STRS-87 

The STRS infrastructure shall contain a callable 
STRS SetTime method as described in Table 8-54. 

OE 

WFCCN 


STRS-88 

The STRS infrastructure shall contain a callable 
STRS Synch method as described in Table 8-55. 

OE 

WFCCN 


STRS-89 

The STRS platform provider shall provide an STRS.h fde 
containing the STRS predefined data shown in Table 8-56. 

OE 

OE script & 
WFCCN 


STRS-90 

The STRS Operating Environment shall provide the 
interfaces described in POSIX IEEE Standard 1003.13-2003 
profile PSE51. 

OE 

Inspect 


STRS-91 

STRS Applications shall use POSIX methods except for the 
unsafe functions listed in Table 8-57. 

App 

Script 


STRS-92 

The STRS platform provider shall provide the STRS 
platform HAL documentation. The HAL documentation 
shall include, but not be limited to, the following 

• For each method/ function, its calling sequence, return 
values, an explanation of its functionality, any 
preconditions for using the method/function, and the 
postconditions after using the method/function. 

• Information required to address the underlying 
hardware, including interrupt input and output, memory 
mapping, and other configuration data necessary to 
operate in the STRS platform environment. 

Platform 

Inspect 

document 


STRS-93 

The STRS infrastructure shall use the HAL APIs to 
communicate with the specialized hardware via the physical 
interface defined by the platform provider. 

OE 

No 


STRS-94 

An STRS platform shall accept, validate, and respond to 
external commands. 

OE 

Observe 
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Requirements 

Description 

OE/App 

Tested 

OK? 

STRS-95 

An STRS platform shall execute external application 
control commands using the standardized STRS APIs. 

OE 

WFCCN 


STRS-96 

The STRS infrastructure shall use the STRS Query’ method 
to service external system requests for information from an 
STRS application. 

OE 

Inspect 


STRS-97 

An STRS application shall use the STRS Log and 
STRS Write methods to send STRS telemetry set 
information to the external system. 

App 

Inspect 


STRS-98 

The STRS platform provider shall document the necessary 
platform information (including a sample fde) to develop a 
pre -deployed application configuration file in XML. 

OE 

Inspect 
document & 
sample file 


STRS-99 

The STRS application developer shall document the 
necessary application information to develop a pre-deployed 
application configuration file in XML. 

App 

Inspect 

document 


STRS- 100 

The STRS platform integrator shall provide a pre-deployed 
application configuration file in XML. 

OE 

Inspect & 
check using 
XML Spy 


STRS- 101 

The pre-deployed STRS application configuration file shall 
identify, as a minimum, the following application attributes 
and default values 

• Identification 

• Unique STRS handle name for the application 

• Class name (if applicable) 

• State after processing the configuration file 

• Required resources 

• Memory in bytes 

• Number of gates or logic elements 

• Configuration parameters containing the STRS handle, 
names of files, devices, queues, waveforms and 
services needed by the STRS application 

• Values and constraints for all operationally 
configurable parameters 

• Filename(s) of loadable images for resources 

App 

Inspect 


STRS- 102 

The STRS platform provider shall provide an XML schema 
to validate the format and data for pre-deployed STRS 
application configuration files, including the order of the 
tags, the number of occurrences of each tag, and the values 
or attributes. 

OE 

Inspect & 
check using 
XML Spy 


STRS-103 

The STRS platform provider shall provide the tools and 
documentation to transform pre-deployed application 
configuration file in XML into a deployed application 
configuration file. 

OE 

Inspect 
document & 
tools 


STRS- 104 

The STRS platform integrator shall provide deployed STRS 
application configuration file for the STRS infrastructure to 
place the STRS application in the specified state. 

OE 

Inspect 
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APPENDIX G — Document Compliance Testing Guidelines 

The document review process is initiated by lead(s) being assigned. The lead(s) will find the deliverable documents 
to be reviewed for STRS compliance and assign the documents to reviewers. If there is submission by more than 
one company, it is recommended that reviewers look at similar documents for two companies to be able to compare 
and contrast. If there are more documents than reviewers, the lead(s) may assign multiple short documents to a 
reviewer or request additional reviewers. The lead(s) will create a spreadsheet or database in eRoom or something 
equivalent for reviewers to enter their comments. The lead(s) will coordinate the review process specifying 
deadlines, sending out reminders and answering questions. 

Then the reviewers will review the documents and enter their comments into the spreadsheet or database. Some 
comments may be STRS changes only and nothing fed back to company, or company comments only and no STRS 
change. The reviewers should keep track of both compliances and non-compliances to be sure that all requirements 
are addressed. 

Once the reviewers have finished, the lead(s) will review the comments for clarity and completeness. Comments 
pertaining to STRS Architecture only are reviewed by the STRS team for inclusion into the STRS Architecture 
Standard with the resolution passed back to the lead(s) for inclusion into the spreadsheet or data base. The lead(s) 
will then prepare company feedback. 

Here is specific guidance to document reviewers for STRS compliance: 

a. Look for meeting the requirements in the STRS Architecture Standard. Reviewers need to record when a 
document satisfies the requirements for that document and not just the variances. The purpose is to be able to 
see if they missed anything. 

b. Look for common practices that might be standardized. 

c. Look for misunderstandings. 

d. For the FPGA wrappers, see what commonalities help future waveform developers and what is platform 
specific. 

e. Determine if we should have a common document format. 

f. Look for items that contribute to waveform (firmware) portability that may become part of the standard. 

g. For STRS, look at their description of their implementation. Did they interpret the APIs as intended? Do we 
need more in our API descriptions, etc? Are there other aspects that should become part of the STRS standard? 

h. For HIDs, see what types of resources are made available to waveform developers. Look for common 
formatting, etc. Determine if we should have a common document format. 

From STRS Architecture Standard version 1.02: 

1. (STRS-4) The STRS platform developer shall describe in the HID document, the behavior and 
capability of each major functional device or resource available for use by waveforms, services, or 
other applications (e.g. FPGA, GPP, DSP, memory), noting any operational limitations. 

Although not in the requirements, some things to look for are: 

a. Identification 

i. Manufacturer, 

ii. Model number, 

iii. Part number and any revision levels (if applicable). 

iv. Device type 

b. Performance capabilities: 

i. Microprocessor clock speed(s) or MIPS 

ii. Data I/O rate maximum in bits per second 

iii. Memory size(s), type(s), and speed(s) 

iv. Reconfigurable capacity 

2. (STRS-5) The STRS platform developer shall describe in the HID document, the reconfigurability 
behavior and capability of each reconfigurable component. 
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3. (STRS-6) The STRS platform developer shall describe in the HID document, the behavior and 
performance of the RF modular component(s). 

Although not in the requirements, some things to look for are: 

a. Receiver information: 

i. Input impedance 

ii. Center frequency 

iii. Bandwidth(s) 

iv. IF frequency(s) 

v. IF input/output level(s) 

vi. Signal to Noise Ratio (SNR), in dB 

vii. Dynamic Range 

viii. Receiver sensitivity 

ix. Third Order Intermodulation Intercept Point (IP3) 

x. Overall receiver Noise Figure, in dB 

xi. AGC operational parameters 

xii. Carrier frequency accuracy 

xiii. Tuning frequency resolution 

xiv. Selectivity in dBc 

b. Transmitter information: 

i. Output impedance 

ii. Carrier center frequency 

iii. Bandwidth(s) 

iv. Operational frequency bandwidth 

v. Intermediate frequencies 

vi. IF input/output levels 

vii. Local oscillator phase noise 

viii. Signal to Noise Ratio in dB 

ix. Output signal flatness over operating frequencies 

x. Temperature vs. Power output 

xi. ldB compression point 

xii. Tuning frequency resolution 

xiii. Carrier frequency accuracy 

xiv. Maximum reverse power at output connector 

xv. Voltage standing wave ratio (VSWR) measured across operating frequency 

4. (STRS-7) The STRS platform provider shall describe in the HID document, the interfaces that are 
provided to and from each modular component of the radio platform. 

Although not in the requirements, some things to look for are: 

a. Electrical connection 

i. Name 

ii. Data type (serial/parallel, digital/analog) 

iii. Bus width 

iv. Timing diagram 

b. Hardware 

i. Describe conduction cooling paths, or specify air-flow capabilities, depending on the 
intended operational environment 

ii. Total heat dissipation limits, and dissipation limits for individual module slots, as 
appropriate 

iii. Thermal cooling requirements 

iv. Operational and storage environmental constraints (temperature, humidity, etc.) 
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v. Mechanical information required to build a module for the platform. This includes all 
dimensions, mass, clearances, mounting method, and connector locations. 

vi. Vibration loading limitations 

c. Table 20 provides typical interface characteristics: 

Table 20 - STRS Module Interface Characterization 


STRS Module Interface Characterization Table 

Parameter 

Description / Comments 

Name 

Interface Name (data, control, DC power, RF, security, etc) 

Interface type 

Point to point, point-multipoint, multipoint, serial, bus, other 

Implementation level 

Component, module, board, chassis, remote node 

Reference documents / Standards 

Applicable documents for interface standards or description 
of custom interfaces 

Note / Constraints 

Variances from standards, physical and logical functional 
limitations 

Transfer speed 

Clock speed, throughput speed 

Signal definition 

Description of functionality and intended use 

Physical Implementation 

Technology 

e.g. GPP, DSP, FPGA, ASIC and description 

Connectors 

Model number, pin out (inch unused pins) 

Data plane 

Width, speed, timing, data encoding, protocols 

Control plane 

Control signals, control messages or commanding, interrupts, 
message protocol 


Functional Implementation 

Models 

Data plane model, control plane model, test bench model 

Power 

Voltages, currents, noise, conducted immunity, susceptibility 

APIs 

Custom or standard, particular to OS environment 

Software 

Device drivers, development environment & tool chain 

Logical Implementation 

Addressing 

Method, schemes 

Channels 

Open, close 

Connection type 

Forward, terminate, test 


5. 


6 . 


(STRS-8) The STRS platform provider shall describe in the HID document, the control, telemetry, and 
data mechanisms of each modular component (i.e. how to program or control each modular component 
of the platform, and how to use or access each device or software component, noting any proprietary 
aspects). 

Although not in the requirements, some things to look for are: 

i. Connector type 

ii. Connector pinout (including unused pins) 

iii. Electrical signaling specifications (logic standard, terminations, etc.) 

iv. Signal timing (setup and hold times, clock rates, clock accuracy, etc.) 

v. Electrical isolation 

vi. Data encoding (Non-return to zero (NRZ), Manchester, etc.) 

vii. Data transfer protocol 

(STRS-9) The STRS platform developer shall describe in the HID document, the behavior and 
performance of any power supply or power converter modular component(s). 

Although not in the requirements, some things to look for are: 

i. Minimum, maximum, and nominal voltages required 

ii. Standby and maximum current availability and consumptions 
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iii. Connector type and pinout 

iv. Voltage ripple tolerance 

7. (STRS-92) The STRS platform provider shall provide the STRS platform HAL documentation that 
includes the following: 

■ For each method/ function, its calling sequence, return values, an explanation of its functionality, 
any preconditions for using the method/function, and the postconditions after using the 
method/function. 

■ Information required to address the underlying hardware, including interrupt input and output, 
memory mapping, and the configuration data necessary to operate in the STRS platform 
environment. 

8. (STRS-12) Application development artifacts shall be submitted to the NASA STRS Repository. 
Although these aren’t required until the final submittal, some things to look for are: 

i. License agreements for software use and reuse. 

ii. High level system or component software model 

iii. Documentation of application firmware external interfaces (e.g. signal names and 
descriptions, signal polarity and format, timing constraints of signals) 

iv. Documentation of STRS application behavior 

v. Description of application function sources 

vi. Description of application libraries, if applicable 

vii. Documentation of application development environment and tool suite 

viii. Include application name, purpose, developer, version, and configuration specifics 

ix. Include the hardware on which the application is executed, its OS, OS developer, OS 
version, and OS configuration specifics 

x. Test plan and results documentation 

xi. Identification of Flight Software Development Standards used 
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